Introduction

Ce document est rédigé avec 3 objectifs :

  • Comparer sur un plan méthodologique les distanciers OSRM et Metric
  • Analyser les différentes pratiques entre OSRM et Metric, en particulier les différences de résultats et leurs conséquences possibles.
  • Identifier des pistes d’amélioration pour contribuer à développer OSRM afin qu’il remplisse entièrement les besoins des SSM/SSP.

A propos du calcul de trajets

On souhaite comparer les résultats de deux outils de calcul d’itinéraires (distanciers) : OSRM et Metric.

Metric est un outil développé par l’INSEE depuis des années. A la DREES, des calculs de distances doivent être réalisés pour des millions ou des milliards de paires et l’outil Metric est utilisé depuis plusieurs années.

Par exemple : 36k communes => 1 milliard de paires de trajets asymétriques.

Les fichiers précalculés de distances de centre communal à centre communal fournis avec l’outil ne sont pas suffisants, par exemple on souhaite connaître le temps d’accès à une maternité en utilisant la position précise de l’établissement. Bien sûr on trouve des astuces pour ne pas calculer les 36k x 500 trajets. On commence par un calcul à vol d’oiseau pour retenir les 3-5 plus proches maternités de chaque commune puis on calcule les 100-200k trajets. Ces calculs se comptent en heures avec l’outil Metric. Nous avons donc souhaité tester l’outil OSRM qui est très connu pour cet usage.

D’autant qu’OSRM a une licence bien plus ouverte que Metric, ce qui rend les travaux fondés sur OSRM plus facilement reproductibles.

Les calculs avec OSRM sont très rapides, mais les requêtes avec le serveur de calcul router.project-osrm.org sont limitées en nombre, nous avons donc déployé une instance locale sur une machine virtuelle fournie par la DSI des ministères sociaux.

L’outil Metric est enrichi de fonctionnalités de cartographie, de manière similaire, une package R (nommé osrm) a été développé par des chercheurs du CNRS https://github.com/rCarto/osrm proposant également la cartographie d’isochrones, ainsi que des trajets avec étapes.

Pour ces deux outils, on fait l’hypothèse que l’usager roule toujours à la vitesse limite, et pour ajuster la vitesse de conduite on modifie virtuellement la vitesse limite.

Metric

Les calculs de trajets de commune à commune s’appuient sur les routes IGN-BDTOPO d’importance 1 à 4 et excluent donc les routes d’importance 5 (desserte locale infra-communale), contrairement au calcul de trajets en infra-communal.

Ceci pourrait conduire à une sur-estimation du temps de trajet pour des communes adjacentes.

Les trajets de commune à commune sont les trajets qui relient les chefs lieux des communes.

Vitesse par segment de route

Ajustement des vitesses limites selon les routes et les densités de population dans les carreaux en utilisant 3 tranches :

  • <500 habitants/km² (pas d’ajustement)
  • [500-4000] habitants/km²
  • >4000 habitants/km²
Moins de 500 hab/km² Entre 500 et 4000 hab/km² Plus de 4000 hab/km²
Autoroute HC 120 100 60
Autoroute HP 120 100 * 0,8=80 60*0,6=36
Quasi-autoroute HC 100 90 40
Quasi-autoroute HP 100 72 24
Route à 2 chaussées HC 90 * sinuosité - 0,1 * pente² max(60 * sinuosité - 0,1 pente² , 15) max(30 * sinuosité - 0,1 * pente², 15)
Route à 2 chaussées HP 90 * sinuosité - 0,1 * pente² 0,8 * max(60 * sinuosité - 0,1 pente² , 15) 0,6 * max(30 * sinuosité - 0,1 * pente², 15)
Route à 1 chaussée HC max(65 * sinuosité - 0,1 * pente², 15) max(40 * sinuosité - 0,1 pente², 15) max(20 * sinuosité - 0,1 * pente², 15)
Route à 1 chaussée HP max(65 * sinuosité - 0,1 * pente², 15) 0,8 * max(40 * sinuosité - 0,1 pente², 15) 0,6 * max(20 * sinuosité - 0,1 * pente², 15)
Route empierrée HC/HP 20 20 20
Chemin HC/HP 20 20 20
Bac auto HC/HP 13 13 13
Bretelle HC/HP 60 60 60

OSRM

La méthodologie qui permet de préparer les données et réduire l’information pour accélérer les calculs à la volée est décrite ici Schéma de pré-processing

Comparaison pratique OSRM - Metric

Metric OSRM
Graphe utilisé Graphe construit à partir de la BD topo de l’IGN, millésimé 2012. Mise à jour possible mais coûteuse en temps. OpenStreetMap (base de données collaborative, mise à jour en continu)
Exhaustivité du graphe Graphe plutôt ancien, datant de 2012 Variable selon le territoire. Exhaustivité et qualité plus élevées en milieu urbain
Trafic (heure pleine) Vitesse théorique, calculs en heures creuses et en heures pleines. Application d’un coefficient réducteur des vitesses limites selon la densité de population dans le carreau. Par défaut, non, mais Possibilité de définir un fichier de profil car.lua ad-hoc avec des vitesses limites par type de route et pénalités/interdictions d’accès spécifiques par type de route, très facile à paramétrer. Possibilité d’intégrer des données de trafic, cf serveur de démo et la doc sous la forme de pondération des arêtes. On pourrait reproduire la méthodologie Metric, mais aussi en développer d’autres avec des données de trafic réelles.
Mode de déplacement Voiture, transport en commun pour Paris, Lyon, Marseille, Loire Voiture, piéton, vélo + profil ad-hoc (camions, heures-pleines…)
Traitements réalisables Calcul de la distance et du temps d’accès entre deux points, calcul de la distance et du temps d’accès à l’équipement le plus proche Calcul de matrices de distance origine/destination, calcul d’isochrones, calcul d’itinéraires
Cartographie Cartographie des carreaux de 200 mètres selon leur temps d’accès à l’équipement le plus proche Calcul d’isochrones et calcul d’itinéraires avec le package R osrm.
Symétrie du graph Symétrique Asymétrique (prise en compte des sens uniques et potentiellement du rôle asymétrique des pentes si l’altitude est ajoutée)
Contraintes Traitement réalisé de commune à commune à l’échelle métropolitaine ou entre des coordonnées précises mais à une échelle départementale Paramétrages supplémentaires lors de l’installation pour tenir compte de l’altimétrie, du trafic routier…
Limites Temps de traitement parfois très long Installation d’une instance en propre nécessaire pour les traitements de masse
Installation Non concerné pour l’Insee, Installation à partir d’une clé USB fournie pour les SSM Compétences pour installer et paramétrer l’instance OSRM, coûteux en temps. Une communauté importante est disponible pour trouver de l’aide, résoudre des erreurs, apporter des améliorations.
Paramétrage Paramétrage des données p.e. les arêtes mais coûteux en temps et non-documenté Définition de fichier de profil et pondération des arêtes avec des données de trafic.
Prise en main Aisée, interface presse-bouton. Utilisation d’API ie utilisation d’un langage de programmation Python/R/JavaScript, etc. même faisable en SAS. Connaissance de base quant à l’utilisation de données géographiques pour manipuler des géo-coordonnées, utiliser le bon référentiel de projection.
Temps de calcul 100 fois plus rapide

Comparaison méthodologique OSRM - Metric

Metric OSRM
Virage Sinuosité = \(\frac{Distance\ à\ vol\ d'oiseau}{distance\ routière}\) Pénalisation avec l’angle réel : \(turn_{duration} =traffic.light_{penalty} + \frac{turn_{penalty}}{1 + \exp^{-\frac{13}{turn_{bias}} \times \frac{turn_{angle}}{180} - 6.5*turn_{bias}}}\)
Ajustements sur la vitesse limite Prise en compte de la densité de population au carreau Définitions modifiale car.lua pour chaque type de route et selon le matériau/texture : herbe, pavement, tartan, goudron…
Prise en compte de la pente/altimétrie (elevation) gradient d’altitude Par défaut, non ! Il faut paramétrer l’installation et en particulier dans le profile.lua, la fonction setup, process_segment en intégrant des données d’altimétrie IGN par exemple, attention au référentiel de coordonnées.ajout en 2014, voici un exemple de mise en oeuvre en Suède
Ajustement à la signalisation Aucun Par défaut, toute signalisation feu tricolore et stop, sous forme de pénalité de X secondes. X est modifiable pourrait servir de proxy pour tenir compte du temps passé au feu pendant les heures de pointe. En outre, paramétrage possible pour ajouter passage piéton selon dispo dans OSM.

Distribution des écarts

Les calculs s’appuient sur des données différentes et des algorithmes différents, il est donc naturel que les résultats diffèrent.

Pour quantifier ces écarts, on utilise un jeu de données qui contient - En observation : des couples de communes représentant une commune de résidence d’un groupe de patient et une commune d’hospitalisation de ces patients - En variables : - Le flux de patient de la commune de résidence vers l’établissement - Le temps de trajet (HP = heure pleine, HC = heure creuse) et la distance (KM) calculés par OSRM et Metric - La population de la commune de résidence des patients - L’altitude moyenne de la commune de résidence des patients

Ecart temps - distance

##                HC        HP        KM Temps_OSRM   KM_OSRM
## Min.      1.00000   1.00000   0.30000    0.40000   0.27500
## 1st Qu.  36.00000  42.00000  35.30000   33.80000  34.12300
## Median   55.00000  62.00000  62.20000   53.40000  60.18700
## Mean     60.25944  67.34876  73.41027   59.24176  70.95406
## 3rd Qu.  80.00000  89.00000 103.60000   80.40000  99.80400
## Max.    199.00000 231.00000 199.90000  188.10000 199.99900

Sur de courtes distances, Metric surestime le temps de trajet par rapport à OSRM.

C’est peut-être parce que Metric ne tient pas compte des routes les plus petites (niveau 5 IGN BDTOPO) pour les trajets intercommunaux.

Lorsque les distances augmentent on remarque surtout une plus grande variance sur les temps de trajet estimés par Metric par rapport à ceux estimés par OSRM pour lesquels le lien temps / kilométrage est plus fort : R² 87% HC, 83% HP vs 94% OSRM.

## [1] 0.8676506
## [1] 0.829217
## [1] 0.94475

Ecart temps - altitude

contours <- rgdal::readOGR("../external_data/GEOFLA_2-2_COMMUNE_SHP_LAMB93_FXX_2016-06-28/GEOFLA/1_DONNEES_LIVRAISON_2016-06-00236/GEOFLA_2-2_SHP_LAMB93_FR-ED161/COMMUNE","COMMUNE")

infos_geo <- contours@data
infos_geo <- infos_geo %>% 
  select(INSEE_COM,Z_MOYEN,POPULATION)%>%
  mutate(POPULATION=as.numeric(as.character(POPULATION)),
         INSEE_COM=as.character(INSEE_COM))
save(infos_geo,file = "contours.RData")
##          Z_MOYEN POPULATION
## Min.       1.000      0.000
## 1st Qu.  104.000    197.000
## Median   187.000    442.000
## Mean     278.313   1779.369
## 3rd Qu.  335.000   1099.750
## Max.    2727.000 458298.000

On peut lire les paires pour une altitude donnée (points sur la même ligne verticale), plus l’altitude est élevée, plus Metric sur-estime le temps de trajet par rapport à OSRM. C’est normal, Metric tient compte de l’altitude et pénalise la vitesse en montagne par la pente alors qu’OSRM n’en tient pas compte dans sa configuration par défaut.

Ecart temps - population

Proportion de communes à moins de X minutes

Pour mesurer l’impact du changement d’outil, on s’intéresse à un problème simple utilisé dans le calcul de certains scores : le nombre d’établissement (resp. de professionnels) situés à moins de X minutes.

Il ressort visuellement que les mesures d’accessibilité sont souvent plus optimistes avec OSRM. De plus, lorsque l’accessibilité calculée avec OSRM est plus forte qu’avec Metric, elle l’est beaucoup plus que lorsque c’est Metric qui donne le meilleur niveau d’accessibilité (asymétrie).

Cohérence temps - flux de patient

Sur l’ensemble des données, le lien entre temps d’accès aux soins et part de patientèle est plus cohérent avec les données OSRM qu’avec les données Metric : R² OSRM = 94% vs Metric = 92%.

## [1] 0.9424593
## [1] 0.9244437
## [1] 0.9230287

OSRM ne tient pas compte des données d’altimétrie, on s’attend donc à ce que les temps d’accès calculés avec Metric soient davantage en adéquation avec la distribution des patients, mais on obtient (pour les communes à plus de 300m d’altitude) un R² identique avec les deux méthodes : 96%. Ici c’est l’argument du temps de calcul qui permet de départager OSRM et Metric. De plus il faut garder en tête qu’il est possible de paramétrer le serveur OSRM pour tenir compte de l’altimétrie.

## [1] 0.9638731
## [1] 0.9618628

Score de type APL

Un risque avec le changement de méthodologie est la modification des scores et donc de certaines politiques telles que le zonage des communes en “zone d’intervention prioritaire”, “zone d’aide complémentaire” ou “zone de vigilance”. Le premier niveau étant appliqué automatiquement lorsque l’accessibilité potentielle localisée est inférieure à 2. Si brutalement certains scores varient de +/- 1 ou même +/- .2 les conséquences pourraient être importantes.

Le calcul de l’APL est complexe

Pour réaliser rapidement une mesure d’impact du passage Metric - OSRM, nous calculons un score plus simple :

offre (séjours disponibles en établissements) / demande (population dans la commune) pondéré par la distance avec un noyau exponentiel (transformation 1/exp(.)).

\(\frac{Offre\ hospitalière}{Demande\ des\ patients}* exp^{-\frac{temps\ d'accès}{20\ minutes}}\)

Les éventuelles dégradations seront faibles mais à l’inverse certaines amélioration du score seront très marquées.

##      Min.   1st Qu.    Median      Mean   3rd Qu.      Max. 
##   0.00002   0.86248   1.83999   3.21379   3.79892 104.67266